Do not report a match for ambiguous sequences #827
Conversation
|
I’ll let this sit here for a while in case anyone wants to object. I initially got the request to enable this behavior using a command-line switch, but ignoring ambiguous matches is IMO the only sensible thing, so I want to make it the default. |
|
A jump to 5.0 would also be a nice moment to look at all the CLI flags and streamline a few things there. From the top of my head, there is a |
|
Ah, I never noticed the inconsistency. I think I can live with that particular one. I want Cutadapt’s CLI to be really stable, even on major version bumps. So there would at least have to be aliases such that old command lines continue to work, but minor inconsistencies aren’t worth it IMO. What’s bothering me more is that the syntax for specifying different lengths for R1 and R2 is And I’d actually lean towards shorter |
This only applies when an index is used. At index creation time, ambiguous sequences (those that would match two or more adapters equally well), are now *removed* from the index. That is, when they are encountered in a read, they will not be assigned to any adapter. The intention is to reduce bias because we previously would report a match to one of the adapters (but which one was more or less randomly determined at index creation time).
This is a backwards-incompatible change, and therefore the version number will be bumped to 5.0.
This only applies when an index is used.
At index creation time, ambiguous sequences (those that would match two or more adapters equally well), are now removed from the index. That is, when they are encountered in a read, they will not be assigned to any adapter.
The intention is to reduce bias because we previously would report a match to one of the adapters (but which one was more or less randomly determined at index creation time).